1. Field of the Invention
The present invention relates to distributed systems configured to process requests provided in different formats.
2. Background of the Invention
Wide area networks such as the Internet provide a convenient forum for engaging in a variety of commercial activities, generally referred to as eCommerce. A typical eCommerce environment 100 comprising buyers and sellers connected by the Internet is illustrated in FIG. 1. In the illustrative buyer/supplier model, a buyer organization 102 has purchased procurement software 103 from a third party vendor. The procurement software 103 allows an individual in the buying organization 102, commonly referred to a requisitioner 104, to use a browser to make purchases. The requisitioner 104 can choose from a list of approved catalogs and shop for the desired items. The catalogs are hosted locally at the buyer organization 102 on a catalog server 106. The catalog information is uploaded to the catalog server 106 by a supplier 110H,1102, . . . 110N. Each supplier 110N is responsible providing their catalog information to the buyer organization 102.
Viewing the catalog, the requisitioner 104 selects the items and quantities needed. When finished, this order is submitted and captured by the procurement software.
The procurement software 103 next notifies a designated approver 108 that a new order request has been placed. The approver 108 is part of the buying organization and uses a browser to view the order and make any necessary changes in price and/or quantities. If the request looks satisfactory, the approver 108 approves the order request.
An approved order request results in a purchase order (PO) message being sent by the procurement software 103 to the appropriate supplier 110N of the goods. The supplier 110N accepts the PO, processes it as necessary and sends a PO response message to indicate that the order was accepted.
FIG. 2 shows an alternative eCommerce environment 200 in which a requisitioner 204 of a buying organization 202 is provided with the ability to shop from a remote catalog hosted directly at the web site of a supplier 210N. In this scenario, the requisitioner 204 again uses a browser to choose an approved catalog to shop from. The procurement software 203 then indicates that the catalog is hosted remotely. The procurement software 203 obtains, either from local storage or from the supplier site, the URL to use for shopping the catalog and returns this information to the browser of the requisitioner 204. The requisitioner 204 then shops the remote catalog and places items in a shopping cart. Upon completion, the requisitioner 204 confirms the order and checks out. The supplier 210N is then responsible for sending the shopping cart contents to an approver 208 of the buyer organization 202. The remaining steps are as those described with reference to FIG. 1. Thus, the approver 208 approves the order and causes a PO to be sent to the supplier 210N. The supplier 210N processes the PO by integrating it with back-end applications or by directing it to a commerce application for processing.
One problem with conventional eCommerce systems is that the buying organizations are installing newer versions of procurement software in an attempt to streamline the purchasing process and reduce expenses. These versions utilize protocols not supported by the legacy systems of the suppliers. These protocols include XML-based protocols, such as Commerce XML (cXML), which allow buyers to communicate with multiple seller organizations. Accordingly, buyers are motivated to do business with suppliers that support the new protocols. Suppliers must therefore support these new protocols or be at a competitive disadvantage to those sellers who do support the protocols. To this end, suppliers must either install new applications or find a means to support the new protocols using the existing order processing software (e.g., reprogram the legacy equipment). Installing new applications and reprogramming existing software are both cost prohibitive and therefore not viable solutions.
There are several existing products that attempt to address integration of existing business solutions with defined B2B protocols. In general, exiting solutions allow an XML formatted message to be mapped to one or more business applications for processing. However, the user is required to have knowledge of all fields in the XML message that apply to a given type of B2B request. Furthermore, some products require a unique adapter program to be generated for each B2B request type to be mapped to a given business application. This adapter program must be ported, compiled and installed on the platform hosting the target business applications.
Therefore, there is a need, in an eCommerce environment, to process requests having various formats including formats not originally/directly supported by supplier's applications.